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ABSTRACT 

Design by Contract (DbC) and runtime enforcement of program as- 
sertions enables the construction of more robust software. It also 
enables the assignment of blame in error reporting. Unfortunately, 
there is no support for runtime contract enforcement and blame 
assignment for Aspect-Oriented Programming (AOP). Extending 
DbC to also cover aspects brings forward a plethora of issues re- 
lated to the correct order of assertion validation. We show that there 
is no generally correct execution sequence of object assertions and 
aspect assertions. A further classification of aspects as agnostic, 
obedient, or rebellious defines the order of assertion validation that 
needs to be followed. We describe the application of this classi- 
fication in a prototyped DbC tool for AOP named CONA, where 
aspects are used for implementing contracts, and contracts are used 
for enforcing assertions on aspects. 



1. INTRODUCTION 

Design by Contract (DbC) 1 22 ] is a methodology for software con- 
struction that is based on runtime enforcement of assertions. Sev- 
eral object-oriented programming (OOP) languages follow the Eif- 
fel 1231 example in providing support for DbC (including, e.g., 
Blue 1141 and Sather 1241 ). Unfortunately, no aspect-oriented pro- 
gramming (AOP) language offers support for DbC. This paper ex- 
tends DbC for controlling also the interactions between advice and 
methods 1251 . a need that is evident in any non-trivial AOP appli- 
cation development 1111 . 

While runtime contract enforcement and blame assignment for ob- 
jects is well understood, it is unclear how DbC extends to aspects. 
In DbC for OOP, assertions are enforced during method invocation; 
a failure clearly implicates one of two distinct objects, the caller or 
the callee. In DbC for AOP, there are two kinds of entities (ob- 
jects and aspects), two different kinds of assertions (assertions for 
objects and assertions for aspects), and no implicit caller (for an 
aspect's advice). 



DbC for OOP also validates logical implications between super- 
type assertions and subtypes assertions on methods 1 9 1: an overrid- 
ing method must be a behavioral substitute 1181 for its overridden 
counterpart. In comparison, DbC for AOP must validate that the 
method with an advice is a behavioral substitute for its advice-less 
counterpart. 

These differences brings about several issues: 

(i) At what point during the execution of the program should 
each kind of assertion be checked? 

(;'(') Should there be a connection between assertions on methods 
and assertions on advice and how should that be enforced at 
runtime? 

(Hi) How is blame assignment affected? 

In this paper we extend the classic DbC runtime contract enforce- 
ment mechanism to cover AspectJ's 12011121 131 advice definitions. 
We concentrate on the impact of the relative interleaving order of 
object contract checking and aspect contract checking. 

In Section|2| we show that there is no generally applicable correct 
order. In Section|3| we develop a classification of aspects accord- 
ing to the way they influence object contracts. We classify each 
aspect as either agnostic, obedient, or rebellious, and show that the 
membership of an aspect in one of the defined categories implies a 
particular order. Based on this classification, the execution order of 
method invocation (and its advice and assertions) changes, in order 
to properly assign blame for any contract violations that may occur. 

Enforcing contracts via aspects is also an application area of as- 
pects that serves as an illustration for the need to differentiate be- 
tween agnostic, obedient, and rebellious aspects. In Section|4] wc 
present CON A (21 29 28 26], a tool for the provision and enforce- 
ment of DbC in both OOP and AOP. 

2. MOTIVATING EXAMPLE 

Consider a software system for an online bookstore (Figure^ with 
offices in the USA, Greece, and Israel. A book sale transaction re- 
quires a non-empty ISBN number (pre-condition of OnlineBook- 
Store.sale). The sale completes by providing a book that either 
matches the requested ISBN number or has the same title (post- 
condition of OnlineBookstore.sale) but possibly a different ISBN. 
The post-condition in OnlineBookstore.sale permits to substitute 
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OnlineBookstore 



+ sale(ISBN):Book 
@pre{ISBN != null} 
@post{result.ISBN.equals(ISBN) 
|| ISBN.getTitle() = result.getTitleO} 



USBranch " 



+ sale(ISBN):Book 

@pre{ISBN != null} 

@post{result.ISBN.equals(ISBN) 
|| (result.ISBN != ISBN && 

result.getTitleO = bookDB.getTitle() && 
result.getBookTypeC) = HC && 
bookDB.getBookType(ISBN) = PB && 
result.getShippingO< 20)} 



ILBranch 



+ sale(ISBN):Book 

@pre{ISBN != null} 

@post{result.ISBN.equals(ISBN) 
|| (result.ISBN != ISBN && 

resultgetTitleO = bookDB.getTitle() && 
result.getBookTypeO = HC && 
bookDB.getBookType(ISBN) = PB && 
result.tCost()-Calc.tCost(ISBN)< 10)} 



CjRBranch 

+ sale(ISBN):Book 
@pre{ISBN != null} 
@post{result.ISBN.equals(ISBN) 
|| ISBN.getTitle() = result.getTitleO} 



Figure 1: The online bookstore has offices in USA, Greece, and Israel. Each site has different taxes (Sales, VAT) and also different 
shipping agencies, sale is overwritten, however, the contracts associated with each method implementation make the three subclasses 
proper behavioral subtypes of OnlineBookstore. 



the requested book with a different edition of the book 1 (e.g., a pa- 
perback (PB) version instead of a hardcover (HC) version, or vice 
versa). 

Concrete subclasses of OnlineBookstore specialize sale to reflect 
the policy in effect in each of the three different countries. Specifi- 
cally, 

• In the USA, an order for a paperback version of a book that 
is not available in the bookstore may be fulfilled with a hard- 
cover version of the book as long as the shipping costs for the 
hardcover version does not exceed the amount of 20 Dollars. 

• In Greece, an order for a book that is not in-stock but another 
version (paperback or hardcover) is available is fulfilled by 
providing that version instead. 

• In Israel, if the requested book is a paperback but the book- 
store has only the hardcover version, then the hardcover is 
provided as long as the difference in the total cost (book price 
plus shipping) is less than 10 Shekels. 

The post-condition on the specialized implementations of sale cap- 
ture the corresponding country's policy, which needs to be checked 
at runtime. 

In terms of contracts (transactions) the role of provider (server) is 
played by the online bookstore software. The consumer (client) 
role is played by the customer that uses the online bookstore soft- 
ware. 

2.1 Contracts in the Presence of Aspects 

Interesting issues arise in the situations where user aspects are present 
in the system where contracts (regardless of how they are being 

'We assume that two books with the same title are either the same 
or different editions of the same book. That is, there do not exist 
two books of different contents with the same title in the bookstore. 



implemented) are used. Since an aspect may observe or alter in- 
formation before, after, or around a method's call/execution, a user 
aspect's advice might: 

• Break a method's pre-condition even when the client calls 
the method correctly. 

• Break a method's post-condition even when the method's 
pre- and post-condition where fulfilled by the method's im- 
plementation. 

• Correct a call to a method m that originally violated m's pre- 
condition. 

• Correct a previously erroneous implementation that did not 
fulfill its post-condition. 

• Add extra behavior to a method's implementation without al- 
tering the set of states accepted by the pre- and post-condition 
assertions, i.e., provide a different mapping for the same in- 
put and output value sets of the method. 

• Add extra behavior by extending the method's specification 
(pre- and/or post-conditions). 

• Monitor a method's execution by collecting information or 
checking certain system properties without affecting the be- 
havior of the method. 

The order of execution amongst aspect advice, pre- and post-condition 
validation, and method execution determines which one of the above 
situations occur. For example, behavioral extension via aspect ad- 
vice should only be allowed when aspect advice is executed before 
a method's pre-condition or post-condition validation. 

Consider (the addition of an aspect that will implement) an in- 
crease of 10% in shipping cost on hardcover books (Listing 0. 
ShippingCost is added to the system and attached to sale method 
calls with an after advice holding the relevant code for the enforce- 
ment of the extra cost. Focusing on sale method calls, it is not 
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Listing 1: ShippingCost aspect adding the 10% extra shipping 
cost on hardcover editions. 

1 aspect ShippingCost{ 

2 pointcut HDSales(ISBN isbn): call(* OnlineBookstore.sales(..) 

) && args(isbn); 

3 

4 after(ISBN isbn) returning (Book item): 
s HDSales(isbn){ 

6 item.setShippingCost(item.getShippingCost() * 1.1); 

7 item.calculateTotalCost(); 

• } 
» } 



obvious what execution sequence amongst pre- and post-condition 
validation, aspect advice and method execution should be followed. 
Three possibilities (Table0 are possible and we will examine each 
one in turn within the context of the on line bookstore example. 

Assuming an execution policy where user aspects are executed be- 
fore pre-conditions and after post-condition are enforced (execu- 
tion order A in Table Q), clients to both the USBranch and IL- 
Branch may be charged more than what was agreed. Although the 
client has maintained the originally agreed upon contract, the final 
outcome breaks the clients expectations blaming the provider. 

The shipping cost increase introduced via the aspect can result to 
shipments where the total shipping cost will be more than $20 and 
a total cost that is more than 10 Shekels. From the clients point of 
view, it is clearly an error of the online bookstore since the agreed 
policy for replacing a paperback edition was not followed. 2 At 
the same time the corresponding branches have assurances (sale's 
post-condition) that the replacement policy was honored. DbC 
mechanisms fail to correctly assign blame in the presence of as- 
pects, misguiding developers and increasing the time spend on bug 
detection and correction. It is clear that the party that is actually at 
fault here is the aspect. One can conclude that the aspect is at fault 
only after observing all three entities, their execution sequence and 
their interactions. 

However, an aspect can also be used to bring about the exact oppo- 
site effect. An aspect can intervene after the return of a method that 
originally returned a faulty result which violated the post-condition 
and modify the result in such a way so that now the post-condition 
is not violated. The execution interleaving would have to allow 
such aspects to intervene before the runtime check for a methods 
post-condition (execution order B in Table0. These situations are 
examples of extensions/fixes through aspects. 

In the case of the online bookstore, suppose that a 20% markdown 
is in effect for all hardcover editions. Consider a customer in Israel 
ordering a book using the ISBN of the paperback edition. Suppose 
the paperback edition costs 80 Shekels and the hardcover edition 
costs 100 Shekels. The bookstore does not have any copies of the 
paperback edition and provides the hardcover edition of the book 
instead. Before applying the 20% markdown on the hardcover edi- 
tion, the post-condition of the ILBranch disallows the switch from 
paperback to hardcover since the difference in cost is more than 10 
Shekels. However if the aspect is allowed to intervene before the 

2 In fact an OOP runtime contract enforcement mechanism will 
blame the corresponding bookstore branch since it does not take 
into account aspects and their specification. 



post-condition check is enforced then the difference in total cost is 
Shekels and the sale can go through. 

One may resort to a conservative approach in which a method's 
pre-condition is checked twice: once before the advice and once 
before the method (execution order C in Table 0. However, that 
would restrict the applicable aspects, thereby compromising obliv- 
iousness (8). 

3. A CLASSIFICATION OF ASPECTS FOR 
DBC 

Aspects can be used: 

(0 to enforce properties without altering the behavior of the un- 
derlying system (e.g., logging the online bookstore system, 
checking the online bookstore coding style 1171 , implement- 
ing the DbC assertions found in FigureQ[cf. Section|4|. 

(if) to allow for extensions to the behavior of the underlying sys- 
tem, (e.g., allowing for extra charges/discounts on the online 
bookstore). 

The two different uses of aspects in the presence of contracts im- 
poses certain restrictions on their execution order. Furthermore, it 
may result in erroneous blame assignments complicating error de- 
tection and resolution. 

The choice of which interleaving execution order (Table to en- 
force also depends on the mechanism of assigning blame in cases 
of violation. Standard DbC mechanisms are ignorant of aspects. 
Blame assignment must therefore be extended to deal with aspects 
as entities that can be assigned blame. Also, what is being violated 
has to be redefined in order to take into account the intention of 
code found in aspect definitions. 

The ability to define an aspect's intentions through a clear declar- 
ative specification as well as the runtime validation of these inten- 
tions is crucial in error detection, error resolution and reasoning 
about aspect-oriented programs. We identify three intentional cat- 
egories of aspects: namely, agnostic, obedient, and rebellious. 

3.1 Agnostic Aspects 

Agnostic aspects are aspects that do not affect a method's asser- 
tions in any way. Agnostic aspects are "sandwiched" with the orig- 
inal method's pre- and post-conditions. From the perspective of 
the callers of the method, the method with the advice (as on body) 
has the same assertions as the original method body. In addition, 
assertions do not change from the method's perspective either. 

3.1.1 Execution Order 

The language imposes the following execution sequence in the case 
of agnostic aspects (execution order C): 

bcf bcf 
JTlprc ~> Oprc ~» a ~* Qpost ~> "Iprc ~> m ~> m post ~> 
„ after „ „ after 

a P re ~» a ~> a post ~> m post 

Where 

• Qp°c denotes to the pre-condition of the aspect's (a) before 
advice 
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Policy 


Execution Interleaving 


Exec Order A 


a ~> 


TTlprc 


~> m ~> m p0 st ~» ol 


Exec Order B 


m P r C ~> 


a 


m ~* a ~> mp 0a t 


Exec Order C 


m prc ~» 


a 


~> rn pro ~> m ~» m post ~> a ~» m post 



Table 1: Three alternative policies of interleaving execution (form left to right) of contracts checking pre- and post-conditions (m pr 
and m post respectively) with advice from an aspect (a). 



a post denotes to the post-condition of the aspect's (a) before 
advice 

m pre denotes to the method's (m) pre-condition 

nipost denotes to the method's (m) post-condition 

Qpi^ denotes to the pre-condition of the aspect's (a) after 
advice 

a P ost r denotes to the post-condition of the aspect's (a) after 
advice 



there should be no change in the method's behavior and specifi- 
cation. Furthermore, the return values of the after advice are the 
return values of the method call as a whole and thus the method's 
post-condition must also hold. 

3.2 Obedient Aspects 

Another form of extension to the base system is one where the set of 
input and output states remains the same but the mapping of input 
to output values changes. In these situations the aspect with such 
an intended extension is categorized as an obedient aspect. 



This execution sequence makes sure that the original method's pre- 
and post-condition is validated both before advice execution and 
after advice execution. 

3.1.2 Blame Assignment 

Runtime assertion validation and blame assignment for agnostic as- 
pects is described in Table|2| On top of checking for each individual 
assertion at runtime extra implications between assertions are val- 
idated to guarantee proper execution flow between aspect advice 
and method implementation. The method's pre-condition has to 
imply the before advice pre-condition making sure that the aspect 
developer took into account the valid start states of the method. 
Furthermore, before advice post-condition has to imply the meth- 
ods pre-condition. Since no alteration of behavior is allowed in 
agnostic aspects execution of the method's implementation must 
start in a valid state satisfying the methods pre-condition. 

Similarly, the method's post-condition must imply the after advice 
pre-condition. This is again the responsibility of the aspect devel- 
oper who is required to begin any agnostic aspect after advice from 
a valid state according to the method's post-condition. Finally, af- 
ter advice post-condition must directly imply the method's post- 
condition. Upon completion of an agnostic aspect's after advice 



Assertion Validation 


Blame Assignment 




Caller 




Aspect 


bet 

™post 


Advice 


„ bet _^ 

"post ' rn-p-cc 


Aspect 


rriprc 


Advice 


Tlpost 


Method 


attcr 
"''post ' " p rc 


Advice 


attcr 
"pre 


Advice 


attcr 
"post 


Advice 


attcr 
"post ' litpost 


Aspect 


m pc .st 


Aspect 



Table 2: Implications for agnostic aspect assertions and blame 
assignment. Order of execution goes from top (first) to bottom 
(last). 



Obedient aspects are aspects used to provide extra behavior with- 
out changing the method's pre- and post- conditions, i.e., obedient 
aspects just provide a different mapping from the same input to the 
same output value sets of the method. From the perspective of a 
caller of the method, the method with the advice has the same as- 
sertions as the original method had. 

3.2.1 Execution Order 

Declaring an obedient aspect imposes the following execution se- 
quence (execution order B): 

bef bef after after 

m pre ~> «prc ~* Q ~> Q post ~» 771 ~» Q pro ~> Q ~> a post ~» m poa t 

Adding an obedient aspect does not alter the pre- and post-conditions 
of the method as they are known to the rest of the system. The first 
assertion validation is still the original method's pre-condition and 
the last assertion validation is the original method's post-condition. 

3.2.2 Blame Assignment 

Once the method's pre-condition has been successful validated this 
should immediately imply the pre-condition for the aspect's before 
advice is also true. The aspect developer knows the method's pre- 
condition and has defined the aspect to be an obedient aspect, it 
is therefore the aspect developer's responsibility to accept all legal 
starting states of the method as legal starting states of the aspect's 
before advice. Failing to do so will signal an error blaming the 
aspect developer for attempting to use an obedient aspect without 
taking into account the original method's pre-condition (Table|5J- 



Assertion Validation 


Blame Assignment 


triple 


Caller 


bet 

TTiprc * "pre 


Aspect 


bef 
" P ost 


Advice 


m * — > n- attcr 

"tpost ' "pre 


Aspect 


after 
Ct prc 


Advice 


after 
'-'-post 


Advice 


after 

"post ' "tpc-st 


Aspect 



Table 3: Assertions validated for obedient aspects (execution 
flows from top to bottom) along with blame assignments. 
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The aspect's before advice post-condition is then checked. Fail- 
ing the before advice post-condition blames the advice code for 
not fulfilling the expected assertion upon its termination. The next 
assertion to be checked is an implication relation between the orig- 
inal method's post-condition and the after advice pre-condition. 
Blame is assigned to the aspect developer in the case of failure, 
for declaring an obedient aspect and not taking into account the 
method's post-condition as a valid start state for the aspect's after 
advice. The after advice pre-condition is then checked, blaming 
the composition rules (pointcuts) in the case of an error. The after 
advice post-condition validation follows which blames the advice 
code in case of an error. Finally an implication between the after 
advice post-condition and the original method's post-condition is 
validated. This check makes sure that the state in which the after 
advice terminates (and thus the whole call to the method) does so 
in valid state according to the method's original post-condition. 

The difference between agnostic and obedient aspects is subtle. In 
both cases, if the method pre-condition is valid, we can invoke the 
method with its advice, and the result satisfies the post-condition. 
However, in the case of the obedient aspect it is possible that a be- 
fore aspect will invalidate the precondition, the method is executed 
on a state that does not satisfy the precondition, and an after advice 
fixes the postcondition (if necessary). With agnostic aspects, the 
method code executes only in the context it was meant for. 

3.3 Rebellious Aspects 

Rebellious aspects are aspects used only to provide behavioral ex- 
tensions to existing methods. Rebellious aspects change the behav- 
ior of existing methods. After the aspect is applied to a method, 
from the perspective of a caller of the method, the method with the 
advice has different assertions than the original method had. How- 
ever, assertions do not change from the method's perspective. 

As the category name implies, these are aspects that are determined 
to alter the behavior of a method to the extend where the existing 
pre- and post-conditions of the method are affected. Nonetheless, 
rebellious aspects can alter a method's pre- and post-conditions in 
a controlled manner: 

• For all valid start states of the method's pre-condition, the 
new pre-condition (aspect's before pre-condition) has to also 
be valid. 

• For all valid states according to the new post-condition (as- 
pect's after post-condition) the original method's post-condition 
has to also be valid. 



The above implications between the extend pre-condition (and orig- 
inal method pre-condition) and extended post-condition (and the 
original method's post-condition) ensure proper behavioral subtype 
between the original method and the extension to the method. 

3.3.1 Execution Order 

A rebellious aspect is guaranteed an execution sequence imposed 
by the aspect that allows its advice to execute even before the method's 
pre-condition. This enables the redefinition of the method's pre- 
condition. In order to allow for the methods behavioral extension 
the execution order enforced by the language is (from left to right): 

bef bef after after 

a P re ~> a ~> a post ~> m prc ~> m ~> m post ~> a pr8 ~» a ~> a post 



In this way an extended version of the method can be provided to 
client programs. This kind of extension, however, raises an issue 
with clients as to which of the methods pre-conditions are clients 
supposed to follow? 

The answer is either one. A rebellious aspect provides a behavioral 
method extension without breaking the existing method's contracts, 
i.e., allows for a broader set of valid start states and a narrower set 
of valid end states. This is reflected in the way implication between 
assertions are being validated, after checking for the validity of 
each assertion, extra implications between pre- and post-conditions 
are further validated. 

3.3.2 Blame Assignment 

Blame assignment is described in Table [4] The extra implication 
m plc — > a p °' makes sure that the extension made through the as- 
pect definition maintains the previously valid start states for the 
method. In case that it does not then the blame lies with the aspect 
developer for providing an extension that breaks existing clients of 
the method. The implication a P oit - ► "ipre verifies that after the 
termination of before advice and before the execution flows to the 
method's implementation, the program state satisfies the method's 
pre-condition. If before the advice post-condition implies the method's 
pre-condition then the method is not being wrongly used by the as- 
pect. The implication m post — > cdj££ r verifies that upon comple- 
tion of the method body execution flows into the aspect's after ad- 
vice in a correct start state for the after advice. It is therefore the re- 
sponsibility of the aspect developer to make sure that all valid states 
reached upon return of the method are also valid start states for the 
aspect's after advice. Finally, the implication a p ^t — * m post veri- 
fies that all the valid states at after advice termination are also valid 
according to the original method's post-condition. This last check 
verifies that the set of valid end states is the same as, or a subset of, 
the original method's set of end states. 



Assertion Validation 


Blame Assignment 


TTLprc > Q^prc 


Aspect 


™prc 


Caller 


^post 


Advice 


bef 

^ P ost TTlpre 


Aspect 




Advice 


?7lpost 


Method 


^^post * ^prc 


Aspect 


„ after 
^pre 


Advice 


after 
™post 


Advice 


after 

L^pc-st ' TTtpost 


Aspect 



Table 4: Implications for rebellious aspect assertions and blame 
assignment. Order of execution goes from top (first) to bottom 
(last). 

3.4 Application and Obliviousness 

A DbC for AOP system is able to provide for the runtime valida- 
tion of assertions on both aspects and objects allowing for the de- 
tection of errors due to erroneous aspect advice implementations, 
erroneous aspect composition and aspect category violations allow- 
ing for faster error detection and resolution. 

The categorization into agnostic, obedient, and rebellious covers 
all behaviors that aspects can introduce to a system. Along with 
the incorporation of pre- and post-conditions for advice, DbC for 



5 



AOP can resolve the execution order question by, e.g., introduc- 
ing three new keywords to the AspectJ language that programmers 
can use to declare the categorizations of aspect implementations. 
DbC support for AspectJ would then use this classification to en- 
force the appropriate execution sequence according to each cate- 
gory. AspectJ could also extend DbC to aspects by allowing pre- 
and post-condition validation for advice and their implication on 
pre- and post-conditions on their attached methods. Such an im- 
plementation of DbC for AOP does not impose any restrictions on 
the base code, allowing the same level of obliviousness 1 8 1 as in the 
current implementations of AspectJ. 

4. A CASE STUDY IN ENFORCING CON- 
TRACTS USING ASPECTS WITH CONA 

So far we tacitly ignored the question of how the enforcement of 
assertions on methods (and on advice) is implemented. Enforcing 
runtime contract checking in a program is a classical cross-cutting 
concern by its very nature of monitoring calls made between soft- 
ware entities I19l | 4| . At the heart of any runtime contract checking 
tool lies the ability to observe and intervene between calls made 
from one software unit to another. The kinds of checks that need 
to be carried out between calls differ depending on the paradigm 
(e.g., functional 1101 vs. OO etc.). The ability of AOP technolo- 
gies to non-invasively extend a system, along with the ability to en- 
capsulate and compose cross-cutting concerns, make AOP an ideal 
implementation tool for DbC. 

CONA |27) is a DbC tool for both OOP and AOP. It extends Java's 
and AspectJ's syntax with contracts and enforces their runtime val- 
idation. CONA works by generating AspectJ aspects to enforce the 
runtime contract checking. CONA generates aspect definitions only 
for the validation of contracts on Java classes; it generates class 
definitions for the validation of contracts on AspectJ aspects. 

In a CONA application there are always two "kinds" of aspects 

1. User-Aspects these are aspect definitions provided by devel- 
opers that affect the underlying Java program. 

2. Contract-Aspects these are generated by CONA and are re- 
sponsible for the enforcement of contracts for objects (DbC 
for OOP). 

and two "kinds" of objects 

1. User-Objects these are all the instances of user defined Java 
classes. 

2. Contract-Objects these are all the instances of the CONA 
generated Java classes used for the runtime validation of con- 
tracts defined inside user aspects. 

Contracts on objects are implemented by contract aspects; con- 
tracts on aspects are implemented by contract objects. The desired 
DbC functionality is guaranteed provided that the generated con- 
tract aspects are the only aspects in the system. However, in the 
presence of user aspects, and in particular, the interplay between 
a contract aspect and user aspects, enforcing assertions correctly 
is non-trivial. CONA is therefore an interesting testbed for expos- 
ing the issues of execution order and a natural client for our aspect 
classification. 



In the remaining part of this section we further explain CONA and 
the language extensions to Java and AspectJ as well as CONA's 
mechanisms for contract enforcement. First an overview of DbC 
for Java is presented followed by a more detailed analysis of how 
CONA extends DbC for OOP to achieve DbC for AOP. 

4.1 An AOP Solution to DbC for OOP 

The AOP implementation for the provision of DbC for OOP maps 
each Java type to a contract aspect that is responsible for the en- 
forcement of all contracts defined in that type. Pre- and post-conditions 
and invariant expressions are generated as aspect methods. Point- 
cuts are generated to capture executions of a type's methods. Point- 
cuts are further used to distinguish which type's method is called 
and which type's implementation of this method is actually exe- 
cuted. In this way the correct type is blamed in the case of a contract 
violation. Extra methods are generated which recursively traverse 
contracts of the current type's supertypes verifying the correctness 
of the type hierarchy. 

Listing [2] shows an example of a contract aspect implementing a 
contract in AspectJ. The code has been generated by CONA (27) 
and it illustrates that aspects implementing contracts can follow a 
pattern (template): pointcut definitions capture calls to the method 
(lines|5J0, before advice checks method pre-conditions (lines|8j- 
1 1 8i . and after advice checks method's post-conditions (lines [191 - 
1291 . Invariant assertions are checked both before and after a call to 
the object's public methods. Auxiliary methods are generated in- 
side aspects to deal with hierarchy checking (lines l36H5H 1 9). The 
recipe for CONA's aspect generation is explained elsewhere 1281 . 

Blame assignment for OOP |9j is summarized in Table|5| The last 
two rows display the type hierarchy check performed in order to 
verify proper behavioral subtyping. Due to the lack of aspectual 
polymorphism 0[6) in AspectJ, the traversal of contracts in CONA 
deploys AspectJ's reflective features in order to acquire aspect in- 
stances at runtime. 

The AOP implementation of DbC for OOP works well as long as 
the generated aspects are the only aspects in the system. 

4.2 An OOP Solution to DbC for AOP 

A DbC for AOP solution has to be able to enforce the execution 
sequence required by each aspect category as well as manage pre- 
and post-conditions found in user aspect definitions. 

Figure|2|uses a flowchart diagram superimposed on an interaction 
diagram showing when obedient (top) and a rebellious (bottom) 
aspects intervene during m's execution, and what is the order of 



Contract Value 


Blame Assignment 


'TTZprc 


Caller 


Vt, r (r -<: t A TV. m A r :: m) — ► 




-i(T::m prc — > r'::m prc ) 


/ 

T 




Callee 


Vr, r (r -<: t A TV. m A t v. m) — ► 




^(r'::m p0 st — > r::m pos t) 


/ 

T 



Table 5: Blame assignment rules for OOP. r' -<: r defines that 
t 1 is a direct subtype of r. r::mpre denotes the method m with 
pre-conditions pre is defined in type r. 
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Figure 2: A flowchart diagram superimposed on a sequence diagram for a method call to m showing the order of contract evaluation 
for obedient aspects (top) and rebellious aspects (bottom). m ple refers to m's pre-conditions assertion and Qprc° rc and QpSst r ° to the 
aspect's pre- and post-condition assertions respectively. 



contract evaluation for these two aspect categories. 3 Aspect cat- 
egory definitions denote a specific order of contract evaluation as 
well as implications between assertions in contract aspects and con- 
tract objects. All diamond shaped decisions points are generated 
by CONA. Decisions points denoted as diamonds in Figure|2|and 
labeled with an a pattern are captured as Java classes (contract ob- 
jects). Diamond shaped decision points labeled with an m pattern 
are captured as AspectJ aspects (contract aspects). 

To support pre- and post-conditions for before and after advice 
we assume the AspectJ language was extended with the keywords 
agnostic, obedient (e.g., Listing|3| line 1), and rebellious, 
and, furthermore, that advice definitions can be annotated with pre- 
and post-conditions that apply to the corresponding advice body 
(Listing |3]lines Q-|Hi- P re ~ ar, d post-conditions are comprised of 
side effect free boolean expressions. 

The extension of CONA for adding contracts to advice takes as in- 
put aspect definitions with pre- and post-conditions. Through a 
preprocessing stage, new aspects are generated to verify contracts 
on object instances and auxiliary class definitions to handle pre- 
and post-conditions on user defined advice. 

First we present a sample program definition of advice with pre- 
and post-conditions along with the generated output. Listing [3] 
shows the obedient ShippingCost aspect presented earlier for the 
online bookstore example written in CONA. Listing [4] shows the 
same aspect as Listing|5|after being processed by CONA. The aux- 
iliary class definitions (Listings [5] and |6j enforce the implications 
between contract objects and contract aspects. 

Pre- and post-conditions inside advice must be side effect free Java 
boolean expressions. These expressions can refer to values that 



3 Agnostic aspects are similar to obedient aspects with some addi- 
tional contract checks interleaved during execution. 



relate to the state of the aspect, and also to the state of the receiver 
and the caller of method invocations. All information concerning a 
join point (e.g. target, args, source, etc.) can be referred to 
from inside an aspect's pre- and post-conditions definitions. 

The programmer must specify the aspect's category and the accept- 
able states in which advice may start/finish. Failing to meet the 
pre-condition of a block of advice implies that the attachment of 
the specific aspect to the base program P is not correct (Listing|4] 
line ll8i and the aspect gets blamed. Similarly, if the post-condition 
of a piece of advice fails, this implies that the code inside the ad- 
vice did not meet up to its obligations (Listing [4] line !15l and the 
advice code gets the blame. 

Once pre- and post-conditions have been satisfied, the way by which 
pre- and post-conditions of advice interplay with method pre- and 
post-conditions of methods that they advice are checked for cor- 
rectness based on the aspects defined category. 

In the case of an obedient aspect (i.e., ShippingCost), before the 
execution of the after advice block the implication between the 
method's post-condition and the after advice pre-condition (List- 
ing |4| line0 is checked by passing control to an auxiliary class 
(Listing [5j. Failing to satisfy this implication throws an Obedi- 
entViolation (Listing [4] line 12 1 1 exception pointing out the er- 
roneous implementation of the aspect's before advice. The ad- 
vice pre-condition and post-condition is then checked, blaming the 
aspect's composition and the after advice implementation respec- 
tively (Listing^ linesfT8landfT5l 

5. DISCUSSION AND RELATED WORK 

We have extended DbC for AOP to handle the interaction between 
pre- and post- conditions of methods and advice. Our goal was pri- 
marily to demonstrate the feasibility a novel approach for support- 
ing DbC for AOP without compromising obliviousness. We have 
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also presented a prototyped tool for enforcing DbC by generating 
aspects. This work paves the road to extending DbC for AOP but 
also leaves for future work a few issues that are need to be worked 
out for a complete practical support of DbC for AOP. 



Listing 2: An aspect definition generated by CONA for enforc- 
ingcontract obligations of GRBranch. 

priviledged aspect GRBranch_Contract { 
GRBranch old; 

pointcut scopeQ: !within(GRBranch_Contract) 
&& !cflow(withincode(* GRBranch_Contract.*(..))); 
pointcut GRBranch_sale(GRBranch tlnst, ISBN isbn): 
call(public * GRBranch. sale(..)) && !call(public * ( 

GRBranch+ && !GRBranch).sale(..)) 
&& args(isbn) && target(tlnst) && scope(); 
before(GRBranch tlnst, ISBN isbn): 
GRBranch_sale(tInst,isbn){ 
boolean next = PreCondHier_sale(tInst,isbn); 
boolean res = PreCond_sale(tInst,isbn); 
if (!res){ 

//pre— condition violation exception 

} 

if (!next){ 

//pre— condition hierarchy violation exception 

} 

} 

after(GRBranch tlnst, ISBN isbn)returning (Book result): 
GRBranch_sale(tInst, isbn){ 
boolean res = PostCond_sale(tInst,result,isbn); 
if (!res){ 

//post— condition violation exception 

} 

boolean postHier = PostCondHier_sale(tInst,result,res,isbn) 

if(!postffler){ 
//post— condition hierarchy violation exception 

} 

} 

public boolean PreCond_sale(GRBranch tlnst, ISBN isbn){ 
return(isbn.notEqual(null)) 

} 

public boolean PostCond_sale(GRBranch tlnst, Book result, 
ISBN isbn){ 

return(result.ISBN.equals(isbn) || isbn.getTitle().equals( 
result.getTitle())) 

} 

public boolean PreCondHier_sale(GRBranch tinst, ISBN isbn){ 
boolean myPre = PreCond_sale(tInst,isbn); 
boolean hierarchy = 
OnlineBookstore_Contract.aspectOf().PreCondHier_sale( 
tlnst,isbn); 
if (Ihierarchy || myPre) 

return my Pre; 
else 
return false; 

} 

public boolean PostCondHier_sale(GRBranch tlnst, Book result 
, boolean last, ISBN isbn){ 
my Post = PostCond_sale(tInst, result, isbn); 
if (!last || myPost) 
return OnlineBookstore_Contract.aspectOf(). 

PostCondHier_sale(tInst, result, myPost, isbn); 

else 
return false; 

} 



} 



Listing 3: An example of using pre- and post-conditions in the 

ShippingCost aspect 

obedient aspect ShippingCost{ 

pointcut HDSales(ISBN isbn): 

call(* OnlineBookstore.sales(..)) && args(isbn); 

after(ISBN isbn) returning (Book item): 
HDSales(isbn){ 
@pre{item.getBookType() = HD} 

@post{item.getShippingCost() = Calc.ShippingCost(item. 

ISBN) * 1.1} 
item.setShippingCost(item.getShippingCost() * 1.1); 
item.calculateTotalCostO; 

} 

} 



Listing 4: Sample output for ShippingCost aspect showing 

the wrapping of advice to check pre- and post-conditions 

aspect Contract.ShippingCost { 

pointcut HDSales(ISBN isbn): 

call(* OnlineBookstore.sales(..)) && args(isbn); 

after(ISBN isbn) returning (Book item): 
HDSales(isbn){ 
boolean implicationl = (new 

Contract_ShippingCost_After_PreCond()).HDSales( 
thisJoinPoint,this,thisJoinPoint.getTarget(),isbn, 
item); 
if (implicationl){ 
if(item.getBookRype()==HD){ 
item.setShippingCost(item.getShippingCost() * 1.1); 
item.calculateTotalCostO; 

if (item.getShippingCost()==Calc.ShippingCost(item. 
ISBN) * 1.1){ 
(new Contract_ShippingCost_After_PostCond). 

HDSales(this,thisJoinPoint.getTarget(),isbn, 
item); 

}else{ 

new Error(this,"before",jp); 

} 

}else{ 

new CompositionError(jp.getTarget().getClass(). 
getName(),this,thisJoinPoint); 

} 

}else{ 

new Obedient Violation(jp.getTarget().getClass(). 
getName(),this,thisJoinPoint); 

} 

} 



Invariants and Object State. DbC makes the obligation-benefit 
contract between software consumers and providers explicit. Each 
instance method defines the valid states in which its execution can 
start (precondition), and the states in which it may terminate (post- 
condition). A more general assertion (invariant), which is main- 
tained before as well as after any externally observable state of 
an object, ensures that the object maintains an acceptable state 
throughout the program's execution. Object and aspect invariants 
can be checked by public methods as part of the pre- and post- 
conditions using the same execution order we have established. 
However, to handle invariants, DbC for AOP needs not only con- 
trol the interaction between aspects and object behavior, but also 
between aspects and object state. It is also not enough to moni- 
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Listing 5: Pre-condition wrapper for aspect after advice 
i import org. aspectj.lang.*; 

3 class Contract_ShippingCost_After_PostCond { 

4 

5 public boolean HDSales(JoinPoint jp, Contract.ShippingCost 



uAspect, Object target, ISBN isbn, Book item){ 

6 String targetType = target. getClass().getName(); 

7 // Holds references to contract (aspects) 

s AspectMethlnvoker alnv = AspectMethInvoker.getInst(); 

10 // call appropriate contracts via reflection 

11 boolean m_post = aInv.invokePost(targetType, jp.getSignature 

(),jp.getArgs(), item); 
n boolean res = (item.getShippingCost() == Calc.ShippingCost( 

item.ISBN) * 1.1); 
B if (Ires || m_post){ 
14 return res; 

» } 
is else { 

n new CompositionError(targetType,uAspect,jp); 

is return false; 

» } 



20 } 

n } 



Listing 6: Post-condition wrapper for aspect after advice 
i import org. aspectj.lang.*; 

3 class Contract_ShippingCost_After_PostCond { 

4 

s public boolean HDSales(JoinPoint jp, Contract.ShippingCost 
uAspect, Object target, ISBN isbn, Book item){ 

6 String targetType = target. getClass().getName(); 

7 // Holds references to contract (aspects) 

s AspectMethlnvoker alnv = AspectMethlnvoker ,getlnst(); 

9 

io // call appropriate contracts via reflection 
n boolean m_post = alnv. invokePost(target Type, jp.getSignature 
(),jp.getArgs(), item); 

12 boolean res = (item.getShippingCost() == Calc.ShippingCost( 

item.ISBN) * 1.1); 

13 if (Ires || m_post){ 

14 return res; 

" } 
i6 else { 

n new CompositionError(targetType,uAspect,jp); 

is return false; 

» } 



tor only call and execution join points. Since advise can change 
the state of an object, the interaction between advice and objects' 
state need to checked to enforce invariants. Additional checks are 
needed for checking the invariant of super-classes and outer classes. 
Invariants for aspects are particularly useful as an inductive hypoth- 
esis: What ever is assumed should be inductively provable. 

Other Kinds of Advice. We have focused on the interaction be- 
tween methods and before and after advice. An around advice 
replaces the method entirely and may or may not contain a pro- 
ceedQ call in its body. Such a narrowing or replacement inter- 



action j!25] should be handled similar to how overriding methods 
handle a call to super. One way of interpreting the aspect anno- 
tation for around advice is to require that an around advice of the 
form f();proceed() would behave like a before advice would, and 
an around advice of the form proceedQ; /() would behave like an 
after advice. 

Introductions and Pointcut Descriptors. We have concerned our- 
selves with the pointcut and advice mechanism in AspectJ. AspectJ 
also support a static OC mechanism (e.g., introductions). This is 
yet another form for a possible interaction between an aspect and 
a class which we do not handle. Another subtle issue is the in- 
teraction between aspects and pointcuts. In our support of DbC 
for AOP we have thus far assumed that pointcuts have no side ef- 
fects. This, however, is not generally true, not even for AspectJ. 
One might consider augmenting pointcut descriptors with pre- and 
post-conditions of their own. 

Aspect Composition Validation Tool. Klaeren et al. 1131 present 
the Aspect Composition Validation Tool for checking pre- and post- 
conditions for aspect compositions according to configurations of 
the system's components. The tool is developed using an older 
version of AspectJ (0.4beta7) which is drastically different than 
version 1.0.6. Further more, a set of configuration rules is added 
through AspectJ's introductions and composition is validated ac- 
cording to these rules. Correctness is defined to be a valid aspect 
configuration that will allow a receiver to perform its task as spec- 
ified by the overall system specification. Unfortunately, checking 
that the behavior of attached aspects and the base system is well 
defined is not verified. As long as the composition of aspects is 
within the set of valid compositions, the system is correct. An as- 
pect can therefore break a methods pre- or post-condition as long 
as the configuration at hand allows it. There is no clear distinction 
between a type's obligations in their system, since the same call to 
an instance of the same type can behave differently depending on 
its aspect configuration. 

JML. Clifton and Leavens (2) use behavioral specifications for as- 
pects as a means to assist in modular reasoning for aspect-oriented 
programs. Aspects are categorized as either observers that do not 
alter the behavioral specification of their attached methods, or as 
assistants that can alter behavior. Their categorization was a result 
after inspecting available AspectJ code and from discussions within 
the aspect community. 

Assertions on aspects as well as objects are expressed in the Java 
Modeling Language (JML) 1161 . The AspectJ syntax is extended 
with three main features: 

1. JML can be used inside aspect definitions, defining the as- 
pect's behavioral specification 

2. Keywords observer and assistant can be used to an- 
notate aspect definitions with their expected intend in the sys- 
tem. 

3. The statement accept (TypePatern) has to be used inside 
modules, making explicit the modules intent to allow assis- 
tance from TypePatern. 

The specification of a method along with its assistant is created as a 
graph by following the possible execution paths, logically and-ing 
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assertions and binding parameter variables and model variables to 
values. 

Although our goals are different than those of Clifton and Leavens 
the proposals share some ideas. Our notion of aspect categoriza- 
tion comes from an analysis of how aspects can affect a program 
execution and not through an analysis of existing usage of aspect 
oriented programming. In doing so we aim at providing a cate- 
gorization that covers any possible usage of aspects rather than 
the common usage of aspects. Further more, our proposal brings 
these categorizations into the programming language and enforces 
an execution order disallowing aspect behavior outside the bounds 
of its defined category. Enforcing an execution sequence helps in 
defining the semantics of assertion validation along with blame as- 
signment without having to resort to long and complicated path 
specifications based on control flow paths. Finally, in our proposal 
modules are not affected in any way and remain oblivious to the 
addition of aspects. Obliviousness is decreased in Clifton et al. (2| 
with the incorporation of the accept expression in the language. 

Pipa. Pipa {3TJ defines a Behavioral Interface Specification Lan- 
guage (BISL) tailored for AspectJ along the ideas of Clifton et 
al. (2). Pipa statements extend the Java Modeling Language (JML) 
to accommodate pre- and post-conditions and invariants for advice. 
Specifications in Pipa, along with aspect definitions, are translated 
to JML and Java code, respectively. Pipa differs from the proposal 
of Clifton and Leaves. Assertions are allowed on aspect introduc- 
tions and the accept expression is not provided by Pipa. Fur- 
ther more, the AspectJ language is not extended to accommodate 
for the definition of observer and assistant aspect defini- 
tions. Behavioral specifications inside aspects are translated into 
JML specifications following the specification generation of exe- 
cution paths as defined in (2|. Pipa does not provide, nor enforce, 
aspect categories. By concentrating on AspectJ's intermediate Java 
representation of aspect programs, Pipa becomes part of the As- 
pectJ compiler making extensions difficult and blame assignment 
more complex. 

Classification system. Rinard et al. 1251 present a classification 
that is also derived from the interaction of advice and methods. 
Their focus is on automated analysis, while our work focuses on 
enforcing contracts based on annotations. The interaction between 
agnostic aspects and methods can be classified as augmentation in 
their classification. The obedient and rebellious aspects we have 
identified refine their combination class of interactions. The nar- 
rowing and replacement interactions can help in extending our work 
to also handle around advice with or without proceed. Their addi- 
tional classification of scopes and field access, can also help in ex- 
tending our DbC tool to handle set-field and get-field advice. Au- 
tomated classification to help suggest or verify aspect categories 
annotation is a direction for future work. 

6. CONCLUSION 

The paper discusses the intricate issues related to DbC for AOP 
The dynamic nature of aspects along with the base system's oblivi- 
ousness render existing DbC methodologies inadequate for dealing 
with aspect-oriented programs. This inadequacy unavoidably leads 
to erroneous error reporting and blame assignment. An extension 
to DbC to address aspect-oriented programming requires more than 
simple assertion validation at each program execution point where 
aspect advice gets to execute. A DbC mechanism for AOP has to 
address both the execution order of contracts (on classes and as- 
pects) as well as the implications (if any) that must be validated 



between contracts on aspects and contracts in classes. Based on 
these decisions of execution order and contract implications, blame 
assignment can be defined. 

We provide an analysis of the possible execution order between 
contracts and view the addition of advice as a behavioral extension 
to the existing program. Our analysis leads us to a categorization 
of aspects into agnostic, obedient and rebellious. Each such cate- 
gorization enforces an execution order between contracts as well as 
the necessary implications that verify at runtime that the extended 
(through aspects) system remains a behavioral subtype of the un- 
extended original system. Error reporting and blame assignment 
is extended to deal with contracted aspect oriented systems. Our 
ideas have been integrated in CONA, an aspect-based DbC tool for 
AOP which uses aspects to implement contracts and their runtime 
validation. CONA serves both as a language extension to Java and 
AspectJ, but also as a case study for our own work. 

Through the development and usage of CONA we hope to improve 
the ability to reasoning about the interactions of aspects with other 
program entities including aspects themselves. We believe that the 
incorporation of pre- and post-conditions on before and after 
advice is a step forward towards reasoning about aspects and their 
behavior. 
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